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t/introduction 



The same important issues from the Appeal Brief and Responses to both Office Actions were left 
unanswered and unresolved by the Examiner's Answer, namely: 
5 L Misrepresentation of the limitations of the claimed present invention as a whole and its 
gist; 

2. Misrepresentation of the Cited Prior Art; and 

3 . Misrepresentation of the law. 

Therefore, this Reply incorporates by reference herein all Arguments from the previously filed 
10 Appeal Brief 

More detailed description of the present invention and prior art is included herein. 
1 . Summary of the Claimed Subject Matter 

15 

Because the claimed present invention has been misunderstood and misrepresented, as shown in 
many instances, its summary is included herein. 

The present invention is not bound by any network architecture and can be used with any number 
20 of multiple tiers, provided that there is one server to unload record data (which are extracted and 
exported from at least one database) and another server to load record data (which are imported 
and stored) in its database. FIG. 1 shows two tiers, target site 100 and server site 2. It is directed 
to solving a special, difficult problem of unloading a result set at a source site 102 (FIG. 1) 
obtained from multiple databases, a separate data transfer of each record pointed to by a cursor 
25 defined by the target site 100, in a record-by-record mode, and loading of each transferred record 
directly into a target site database 104 while other records are being transferred. The term 
loading is defined as loading directly into a database 104, the term unloading is defined as 
unloading directly from a plurality of databases 106. Thus neither loading nor unloading means 
just data access, nor storage in a memory or cache or used for I/O transfer, but into and from 
30 database storage. Database is also defined in the specification as a data source, data depository 
(p. 2. li. 10-16, p. 4 li. 17, p.6 li. 19) or table (p. 3, li, 1, p. 8. , H. 6-10, p. 10. Li. 23, p. 11 li. 20. 
p. 12 li. 1-16, p. 13 li. 13, p. 14, Li. 17, p. 15 H. 7-19, p. 16 li. 4-10, etc.). 
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Target site 100 describes the source of data in the source site 102 with a SQL DECLARE 
CURSOR FOR SELECT statement (p. 8, H. 2-12) which is sent to the source site for execution 
and includes a query, such as a distributed join. LOAD INCURSOR (p. 8, H. 5-12, p. 15. 4-19) 
statement is sent to the source site 102 to request transfer of the query result set and to load the 
5 transferred data into the target site database 104 table. For the purpose of record-by-record mode 
transfer, the present invention defines and uses a new command, INCURSOR (p. 8, li.8-12) to 
reference, transfer and load each record separately, instead of referencing and transferring the 
whole file as taught in the prior art, where the file is referenced by INDDN file name. 

10 Data transfer is performed in the present invention using DRDA interface 118, 120 and 
implemented in DB2 Family Crossloader 112, 114. Data transfer is performed herein in a novel 
way, in a record-by-record mode, and target site loads records concurrently with the unloading of 
records in the source site. Moreover, data transfer is performed during obtainment of records that 
form a result set in the source site 102, as noted in specification on p. 3, li. 8. In record-by-record 

15 mode records are unloaded concurrently with record loading, i.e., transported in asynchronous 
mode. Once the record transport starts, no new requests are sent fi-om the target site until the 
whole result set is transferred. Thus, the present invention does not utilize synchronous transport 
mode which synchronizes each data return with another request and requires the source site to 
wait for another request fi*om the target site for each new record or set of records to be unloaded, 

20 transported and loaded. 

The purpose and benefit of the claimed invention is to avoid limitations and physical constraints 
of the File Transfer System at either the source or the target site, as shown in Specification p. 1, 
li. 23, p. 2, li. 10 - p. 3, li. 8, p. 7, li. 14-21, etc. As shown in Specification, p. 3-6, there are no 

25 known solutions of this problem and the claimed invention proposed a workable solution. File 
Transfer system is used in conventional systems where the whole file is referenced by INDDN 
file name. Claimed invention does not use the File Transfer System because the purpose of the 
present invention is to avoid being bound by the maximum file transfer size. Moreover, the 
present invention saves time by transferring records during obtainment of result set and loading 

30 records into database during the record transfer. This is obtained by accessing records by a cursor 
and by transporting data in record-by- record mode, so that operations of sending one record and 
receiving another record are happening concurrently on a source and target site. 
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Moreover, the present invention allows transfer of data from multiple data sources, possibly 
stored in different formats, by using existing conventional technology, such as a multi-database 
software server DataJoiner and Distributed Relational Database Architecture. Thus, in the 
claimed invention record attributes may span multiple data sources and can provide data in a 
5 neutral data format. Furthermore, record attributes from multiple record sources can be accessed 
within a single transaction. These claimed novel features distinguish over the cited prior art, 
under 35 U.S.C. 103(a), and are described in Figures and Specification on p.2, p. 3, H. 1-8; p. 6, 
li. 18-23, p. 7-8, etc. In the present invention the source site server 102 has multi-database access 
to a plurality of DBMSs 108 and disparate data sources 106 via a Muhi-database server. As 

10 specification and all independent claims 1, 9 and 17 clearly show, the present invention is 
specifically directed to show an improvement of the Multi-database Server database management 
system, invented by the same Assignee under name DataJoiner, which does not provide data 
loading, transfer and unloading to a target site database. DataJoiner software server receives a 
distributed SQL query from a client, performs the query in a multi-database system and provides 

15 a result set at the same server. Data transfer, loading and unloading has to be performed by 
another software. 

Database connection communication line 116 in the present invention is defined in p. 8 as using 
DRDA protocol rules for supporting multi-database access and may use TCP/IP protocol. It 
20 connects the target site 100 with server site 102. It does not connect DataJoiner to data sources 
108. 

Specifically, the independent claim 1 states: 

1. A method for loading data from a remote data source record by record, in a computer system 
25 network connecting a source site and a target site via a database connection communication line, 
the method comprising the following steps: 

(a) coupling the source site to at least one data source and to a software server having 
multi-database access to DBMSs; 

(b) at the target site requesting data loading from the source site via a block of Structured 
30 Query Language (SQL) statements; and 

(c) transporting data record by record via the database connection communication line 
according to a multi-database access communication protocol, wherein the target site loading 
records concurrently with the unloading of records in the source site. 
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Therefore, the present invention, as shown in Specification of p. 4, li. 8-10, p. 6, li. 15-17, and 
pages 7-11, 13, 16-23, teaches in claim 1: "loading data from a remote data source record by 
record", (via Crossloader 1 14 and DRDA interface 118) 
5 (a) coupling the source site (102) to at least one data source (106) and to a software 

server having multi-database access (DataJoiner 124) to DBMSs (108); 

(b) at the target site (100) requesting data loading from the source site (102) via a block 
of Structured Query Language (SQL) statements (DECLARE CURSOR, LOAD INCURSOR, 
Crossloader 112, 124); and 
10 (c) transporting data record by record (Crossloader 112, 1 14 and DRDA 118, 120) via the 

database connection communication line (116) according to a multi-database access 
communication protocol (defined in DRDA interface 118, 120), wherein the target site (100) 
loading records concurrently with the unloading of records in the source site (102). 

15 

2. Summary of the Prior Art IBM DataJoiner ("IBM") 

Multi-database Server database management system, invented by the same Assignee under name 
DataJoiner, does not provide data transport, loading and unloading to a target site database. 

20 DataJoiner software server receives a distributed SQL query fi-om a client, performs the query in 
a multi-database system and provides a result set at the same server. Data transfer, loading and 
unloading has to be performed by another software. DataJoiner uses an innovative global 
optimizer that allows distributed multi-location joins, which is shovm in Figure 1. Figure 1 does 
not specify server locations or tiers and it does not show data unloading and loading, just a join 

25 query and DataJoiner connected to several data sources. 

DataJoiner can be used in any number of tiers. Two-tier system is shown in Figure 3 of page 1 1 
as executing a client application on the DataJoiner site and executing multiple data sources on 
remote sites (p. 10). Three-tier architecture is shown in Figure 4 of page 11 where the client 
30 application accesses DataJoiner server fi*om a remote client site and executes client application 
there. As shown on p. 12, DataJoiner communicates with data sources using DRDA or other 
protocols. Global optimizer moves whole tables from different data sources to perform a join (p. 
12, paragraph 4). 
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The scope and purpose of this reference is to allow access to multiple, disparate databases 
residing on several data sources' databases. Thus, nowhere in this reference is loading and 
unloading even mentioned, only access. Moreover, no data transfer between DataJoiner and a 
client is defined, because it is provided by the client itself and is irrelevant to DataJoiner. The 
5 only communication line described by the reference connects DataJoiner and data sources. 
Further, no transfer in record-by-record mode is shown, and only transfer of whole tables, 
between DataJoiner and data sources is shown, and not transfer of tables to the client. 

Therefore, DataJoiner reference only teaches several elements of FIG. 1 and specification of the 
10 present invention, such as DataJoiner 124, DBMS family 108 and databases 106, used to provide 
access to multiple databases, which cannot provide data unloading at source site, data loading at 
target site and a concurrent record-by-record data transfer between source and target site. 

3. Summarv of the Prior Art Hejlsberg et al OJS Pat. No. 6.15L602) r"Heilsberg"y 

15 

Scope of Hejlsberg reference is a platform-independent self-describing data packet creation 
which can only transfer data fi*om one database source - third tier. It cannot support a multi- 
database server and Distributed Relational Database Architecture, which were known at the time 
of Hejlsberg invention, and nothing in the reference shows any interest in doing so. Thus, this 
20 reference cannot transfer, within a single transaction, data fi-om multiple data sources, stored in 
different formats, where record attributes span multiple data sources. Its data packet is used as a 
file format when storing data temporarily to disk (col. 7, li, 5) and for this purpose it has to use 
the whole file transfer system which is avoided in the present invention. 

25 Hejlsberg reference can only be applied to a three tier system, with a dumb client, an application 
server without a DBMS which processes data, and a database server with one DBMS which only 
stores the data, as described in last paragraph of col. 1 and Fig. 3. Thus, the only DBMS exists in 
the third tier - database server. 

30 Further, Hejlsberg reference can only transport data in packets, in packet-by-packet mode. 
Moreover, in order to provide system-neutral data, for each data packet Hejlsberg has to provide 
a metadata block with data format descriptor, which has to be supplied in a self-described data 
packet, making it large, thus teaching a data transfer which is very slow and very cumbersome 
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(col. 3, li. 34-43). Because of this, data has to be packed in the middle tier before sending and 
unpacked and processed when received by the client. 

Hejlsberg teaches at Col. 7 line 66 to Col, 8 line 10 that a data packet representing ordinary data 
5 can be "partial", meaning the total data packet content can be divided into multiple data packets. 
In this case, only the first data packet contains metadata describing the data. The subsequent data 
packets must include a data packet identifier and multiple data rows. Partial data packets are used 
to reduce data traffic when the user just wants to see the first N number of rows of the results set, 
and later fetch the next set of rows in a partial data packet. Therefore, Hejlsberg divides the total 
10 data content into multiple partial data packets. First data packet, as shown in FIG. 4, has a header 
410, several column descriptors 421, several parameters 425 and variable number of rows 430 
(col. 8, li. 13-18). A partial data packet omits parameters 425. Therefore, in Hejlsberg each data 
packet has metadata and multiple rows. 

15 However, each data row in Hejlsberg reference is special, as defined in a row data layout, in col. 
13, li. 9 to col. 14. li. 41, which state that each row must have iRowtatus and InullBits metadata, 
in addition to row data, needed in that reference but not needed in the present invention. Thus, 
transported data row from Hejlsberg reference differs from the data row of the present invention. 

Further, in the Hejlsberg reference the target site loading of records does not occur concurrently 
with the unloading of records in the source site. As shown in col. 21, li. 5-34, after the packing of 
metadata and all rows in a data packet, in step 506 of Figure 5, end of stream is written in step 
507 to indicate that the memory has the whole data packet and can write it on the disk of 
database server of tier 3, or transport it to client via network. Only after the whole data packet is 
transported in step 601 of Figure 6, col. 21, li. 16, the client starts unpacking for processing the 
metadata and only then it sets up the local data store for receiving the actual data, in step 604. 
Thus, this reference has to perform data processing in the client, in step 605, after it already 
received the data packet, to reconstitute data rows with help of the metadata. 

30 Thus, nowhere does Hejlsberg state that, "when client receives and unloads the first data packet 
contains the first set of record, the next sets of record are still streaming out of the source site, 
and that, therefore, the target site loading of records occurs concurrently with the unloading of 
records in the source site as claimed.", which is a mere unsubstantiated speculation by Examiner. 
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Moreover, the described data packets and partial data packets of Hejlsberg, according to 
specification sections cited above and Fig. 4, clearly show that, there, one packet is not the 
equivalent of one row but contains several rows and metadata and each row has row metadata. 

5 

Partial data packets of Hejlsberg reference, in col. 21, li. 35-46, are sent in synchronous mode in 
this reference because a client has to send another request to fetch a partial data packet with next 
records. This partial data packet also has some metadata in addition to rows, such as data packet 
identifier (col. 8 li. 3) and each row has some row metadata, such as iRov^atus and InuUBits. 
10 Thus, partial data packets are not sent in asynchronous record-by-record mode of the present 
invention. Further, Hejlsberg teaches "on demand" delivery of partial packets, as described in 
col. 8, li. 1-11, which means that a user has to unpack the first sent packet with metadata, check 
some parameters and decide whether he wants to receive other packets and, if so, send a new 
request to fetch next record command, as described in col. 21, li. 35-46. 

15 

Metadata content within each data packet is accessed one piece of information at the time by the 
middle tier. Col. 20, li. 38-67 describe teachings of the reference as using I/O streams to first 
collect and stream out one-by-one each table attribute and only then allows the system to begin 
reading and processing data. Hejlsberg further teaches that processing of data is happening 

20 sequentially (col. 20. li. 49) by streaming out record field values. Sequential access of this 
reference, as defined in col. 7, li. 31-40, only applies during unloading to the client and not while 
packet is being loaded fi-om the target site, as well. In col. 21, li. 14-34 it describes unpacking at 
client's side which allows processing during unloading, both at the client side, but not during data 
transfer. Thus, Hejlsberg teaches sequential transfer and not the concurrent transfer of the present 

25 invention. 

Further, section Col. 7 line 66 to Col. 8 line 10 does not show a target site loading records 
concurrently with the unloading of records in the source site, as stated in Final OflFice Action. 
Instead, this section shows a sequential transfer of a number of packets, where each packet has 
30 limited information including a header and row data. Therefore, there is no showing of a target 
site loading records concurrently with the unloading of records in the source site, as is claimed in 
the present invention. Further Examiner's assumption of "piece of information" and "allow the 
system to process data while it is still being received" is also unsupported by the reference. 
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Thus, Hejlsberg does not transfer data record-by-record but packet-by-packet, where packets 
have to contain additional metadata, have to be pre-packed and unpacked and are cumbersome. 
Moreover, its loading and unloading are not performed concurrently but with pauses for decision 
5 making, wherein the transfer only continues upon explicit request. Moreover, Examiner's citation 
of Hejlsberg col. 7, li. 30-37 is incorrect because it does not even mention "concurrent" transfer 
but explicitly states sequential transfer, which it shows as receiving and accessing content within 
each data packet one piece of data packet metadata information at the time, in col. 7, li. 31-40, 
and not sending and receiving whole records concurrently. Examiner's interpretation of Fig. 3 as 
10 "piece of information" corresponding to row data is also incorrect. Further, Fig. 3 does not even 
show a row. 

Further, as shown above and throughout Hejlsberg reference, these packets are not records from 
a DBMS table, as claimed in the present invention, but metadata attributes, as shown in col. 7, li. 
15 31-40 of reference. FIG. 4 also does not show a record as in the present invention but a 
complicated packet with a header and metadata, in addition to row data, and each said packet has 
to be unpacked to read header and metadata, before storage. 

Further, Final Office Action states that Hejlsberg also provides the advantage of using this 
streaming method which "allows the system to process data while it is still being received ... 
across the Internet". Applicant respectfully points out that data "processing" is not the same as 
transferring, loading, sending or receiving. Further, data processing and receiving in Hejlsberg 
happens on the same site, the client site. In the claimed present invention, target site loading of 
records occurs concurrently with the unloading of records in the source site. 

Further, although Examiner's attempts to proclaim that this reference and the present invention 
are from the same field of streaming videos, please note that neither one even mention any 
videos. 

30 Thus, Hejlsberg reference teaches a platform-independent self-describing data packet creation 
which is from a different field. It cannot support a multi-database server and Distributed 
Relational Database Architecture so it cannot transfer within a single transaction data from 
multiple data sources, stored in different formats, where record attributes span multiple data 
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sources, which was a long felt need. It has to use the whole file transfer system which is avoided 
in the present invention. Further, Hejlsberg reference can only transport data in packets, and 
packet-by-packet data transfer is not the same as record-by-record transfer. Moreover, in order to 
provide system-neutral data, Hejlsberg has to provide a metadata block with data format 
5 descriptor, which has to be supplied in a self-described data packet, making it large, thus 
teaching a data transfer which is very slow and very cumbersome. Because of this, data has to be 
packed before sending and unpacked when received. Therefore, a data packet of Hejlsberg 
reference cannot be perceived as an equivalent of a record of the present invention by a person 
knowledgeable in art, and packet transfer is not an equivalent of record transfer. 

10 

IL ARGUMENTS 

Because the Examiner's Answer grounds for rejection on pp. 3-8 are taken verbatim from the 
Final Office Action, with all grammatical and logical errors, the same important issues from the 
15 Appeal Brief and Responses to both Office Actions were left unanswered and unresolved by the 
Examiner's Answer, namely misrepresentation of the limitations of the claimed present invention 
as a whole and its gist, misrepresentation of the cited prior art; and misrepresentation of the law, 
this Reply incorporates by reference herein all Arguments from the previously filed Appeal 
Brief 

20 

Regarding argument at the bottom of p. 4, please note that no suggestion was made by Hejlsberg 
reference to modify IBM reference which is a gross misrepresentation, apparently intentional, 
because it has never been corrected after numerous Applicant's rebuttals. 

25 Further, please note that no modification or combination has been suggested in any cited prior 
art. 

Response to Examiner's Response to Appeal Brief Arguments f 10) 
30 1. Page 9 Arguments 



Issue of prematureness was to remind the reader that the law should be followed. Filing a 
Petition would only delay response, cost more and send the case back to the same Examiner who, 
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despite all Applicant's attempts to clarify Examiner's misunderstandings of the present invention, 
prior art and laws, did not want to talk to the Applicant's attorney. 



Please see Applicant's description of IBM prior art above and Appeal Brief Number of tiers was 
5 not claimed in the present invention and is irrelevant. DataJoiner can be used anywhere and there 
may be several DataJoiners in an application, as described in the reference. Access to data is not 
the same as loading data into a database after a network transfer. In the present invention 
DataJoiner is on the source 100 site (not middle device) and is only connected to data sources 
106, which are not on source site. 

10 

2. Page 10 Arguments 

Please see Applicant's description of IBM prior art above and Appeal Brief IBM reference does 
not teach loading into target site. Page 7 SQL statement will not load data into the target site 
15 database table. IBM reference does not teach transporting via database connection 
communication line 116. As Examiner's citation clearly states, it only transports between 
DataJoiner 124 and data sources 106. 

3. Page 11 Arguments 

20 

As can be seen from above, the dissection of claims severely clouded Examiner's thinking 
because he was concentrated at finding similar words, such as source, target, database, 
communication, etc. instead of understanding the present invention and each prior art as a whole. 
The only prior art anticipation is DataJoiner 124, DBMS family 108 and data sources 106, which 
25 are clearly marked in FIG. 1 and throughout specification; hence, no further thinking, 
assumptions or dissection was necessary. 

Applicant further objects to dissection of Appeal Brief sentences which are always taken out of 
context. Nowhere in Appeal Brief does Applicant even use words "only difference". Moreover, 
30 tables are moved between DataJoiner and data sources, not between DataJoiner and target site. 

4. Page 12 Arguments 
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Please see Applicant's description of Hejlsberg prior art above and Appeal Brief. Hejlsberg 
reference never teaches that only one row is sent (N is never shown as 1), row has additional 
metadata so it is not synonymous with record of the present invention, as assumed by Examiner. 
Further, in Hejlsberg reference data rows are not divided into multiple data packets, only the 
5 whole data packet is divided in partial data packets. Further, this reference nowhere describes 
streaming as Examiner imagines it in the first fiill paragraph and no concurrency is even 
mentioned in that reference. 

No teaching, suggestion or motivation to combine is found in cited prior art references and 
10 Examiner did not point to one there, either. Even if a combination of IBM and Hejlsberg 
reference would be possible, and it is not, it would never produce the claimed invention because 
the metadata in data packages and rows of Hejlsberg reference, packing all data in its middle tier 
first, before transfer, and unpacking and processing in client before storage would defeat the 
purpose of the present invention, which elegantly sends records as soon as each is unloaded and 
15 stores each records in the database immediately after receipt, without any data manipulation. 

Further, processing in Hejlsberg reference occurs in client site once the data packet is received, 
so it has nothing to do with unloading on the source site, which already sent the whole data 
packet before processing it on the client site. In the present invention, record is unloaded in the 
20 source site concurrently to record loading on the target site. 

5. Page 13 Arguments 

Please see Applicant's description of Hejlsberg prior art above and Appeal Brief Hejlsberg does 
25 not teach streaming video, unclaimed and unmentioned in the present invention. Hejlsberg is not 
concerned with saving time during data transfer between sites in the cited section but during 
processing on client site. Please note that data processing is not even performed in the present 
invention because it is not needed. 

30 No cited prior art is pertinent to the present invention because it is not directed to and does not 
teach, suggested or even mentions unloading, loading and transfer in record-by-record mode, 
which is the problem that Applicant solved in order to avoid use of File Transfer System. 



SVL20010010US2 



Because Examiner here only mentions "three tiers", "response to SQL requests", "source site", 
"target site" and "database server" as commonality of prior art Hejlsberg with the present 
invention, it is obvious that there is no understanding of the analogous art. Because all claims 
were rejected due to some combination of cited prior art, all claim rejections are improper and 
5 claims 1-24 are allowable. 

6. Page 14 Arguments 

No general allegations were ever used in Applicant's paperwork. Examiner points to a conclusion 
10 drawn after numerous well-founded arguments. However, each Examiner's argument and 
element's interpretation is erroneous and motivation is either lacking or faulty. 

Second paragraph statement is also erroneous. Please see discussion above and col. 21 li. 4-34 of 
the reference. 

15 

7. Page 15 Arguments 

Please see Applicant's description of Hejlsberg prior art above and Appeal Brief Hejlsberg does 
not extract in the source site but by the middle tier. Step 507 transmits the whole data packet, as 
20 described in col. 21 li 4-34 of the reference. There is no teaching in this reference that a record is 
transported as soon as a record is unloaded. As a matter of fact, this reference teaches away from 
the present invention because it firstly packs the whole data packet, as shown in col. 21 and FIG. 
5, and only then transports it. 

25 Applicant is very curious to see how a flow chart can show time, i.e., that something happened 
"without waiting", since it is not a time line. This assumption is also very erroneous, just like all 
other Examiner's assumptions, because section in col. 21 li 4-34 and FIG. 5 of the reference 
clearly shows that no transfer happens before whole data packet is prepared for transfer. 

30 Argument in the first fiill paragraph is a repetition and gas already been rebutted above. 

8. Page 16-19 Arguments 
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Please see Applicant's description of Hejlsberg prior art above and Appeal Brief. Arguments are 
a repetition and have already been rebutted above. 

9, Page 20-24 Arguments 

5 

Please see Applicant's Appeal Brief and description and argument above. Arguments are a 
repetition and have already been rebutted above and in Appeal Brief. Gottenmukkala and 
Vassilakis reference have also been misrepresented as shovm in the Appeal Brief They are also 
directed to nonanalogous art and solve different problems and cannot be combined to provide 
10 teachings of the claimed present invention. 

Thus, The Examiner has not established a prima facie case of obviousness because the three 
basic criteria, w^hich must be met, were not met because he did not point out: to any suggestion 
or motivation, either in the references themselves or in the knowledge generally available to one 

15 of ordinary skill in the art to modify the reference or to combine reference teachings, a 
reasonable expectation of success was not shown (and is impossible) and that the prior art 
reference(s), which must teach or suggest all the claim limitations, do so here, which they do not. 
Furthermore, the Examiner did not satisfy the initial burden to provide some suggestion in the 
references of the desirability of doing what the inventor has done, because to support the 

20 conclusion that the claimed invention is directed to obvious subject matter, either the references 
must expressly or impliedly suggest the claimed invention or the examiner must present a 
convincing line of reasoning as to why the artisan would have found the claimed invention to 
have been obvious in light of the teachings of the references. 

25 Furthermore, Applicant repeatedly pointed out that the cited references are from nonanalogous 
art. The law states that referenced art must either be in the field of applicant's endeavor or, if not, 
then be reasonably pertinent to the particular problem with which the inventor was concerned 
that logically would have commended itself to an inventor's attention in considering his problem. 
Since there are great differences in problems solved, their solution, function and structure it is 

30 obvious that the cited four references are each from a different field and none is from the field of 
the present invention. Therefore, the Examiner has not established a prima facie case of 
obviousness and the rejection under 103 is invalid. Therefore, the independent claims 1, 9, and 
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17 and their dependent claims are valid and recite novel and nonobvious features that patentably 
distinguish over the cited references. 

TTI CONCLUSION 



As noted above, none of the stated references shoves, suggests or teaches data loading in record- 
by-record mode, as claimed in the present invention. Improper combination of cited references is 
used in each claim rejection in the Final Office Action, because none of the cited references 
suggests combination or modification. Therefore, all submitted claims are allowable over the 
10 cited references and their reconsideration is respectfiilly requested. 

In light of the above arguments, it is submitted that the final rejections of claims 1-24 are 
improper and, accordingly. Appellant respectfiilly requests a decision by the Board of Patent 
Appeals and Interferences reversing the Examiner and directing allowance of all pending claims 
15 in this application. 
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Respectfiilly submitted. 
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